(19) 



J 




(12) 



(43) Date of publication: 

14.04.1999 Bulletin 1999/15 

(21 ) Application number: 97402362.4 

(22) Date of filing: 07.1 0.1 997 



Europaisches Patentamt 
European Patent Office 
Off ice europeen des brevets (11) EP 0 909 094 A1 

EUROPEAN PATENT APPLICATION 

(51) Int CL«: H04N 7/173, G06F 9/46 



(84) Designated Contracting States: 


• Yang, Rui Liang 


AT BE CH DE DK ES R PR GB GR IE IT LI LU MC 


7501 7 Paris (FR) 


NL PTSE 






(74) Representative: 


(71) Applicant: 


Cozens, Paul Dennis et al 


CAN ALt Soclete Anonyrne 


Mathys & Squire 


75711 Paris Cedex 15 (FR) 


1 00 Grays Inn Road 




London WC1X8AL(GB) 


(72) Inventors: 




• Liao, Hongtao 




781 80 Montlgny-Btx (FR) 





(54) Multith read data processor 

(57) An apparatus for processing digital audio-vis- 
ual data, in particular a receiver/decoder for a digital tel- 
evision system, conrprising one or more hardware 
devices for transmission and reception of data, the 
hardware devices having at least one associated hard- 
ware operating system 41 00, the decoder further com- 
prising a data processing system including a multi- 
thread virtual machine 4250 adapted to, inter alia, 
receive event messages signalled by the hardware 
operating system and to assign corresponding event 
objects 4564 to one or more threads 4561 , and in which 
a thread including an event object may be suspended 
during the course of its execution to permit the execu- 
tion of another thread. 



4^62. 

-A 




< 

o 

(J) 
o 

o 

Q. 

LU 



Pnnteo Dy Xerox (UK) Business Services 

2.16.7/3.6 



BNSDOCID: <eP „ O909O94At„t,> 



1 



EP0gO9 094 A1 



2 



Description 

[0O01 ] The present invention relates to an apparatus 
for processing digital audio-visual data, in particular a 
decoder for a digital television system including a multi- 
thread data processor. 

[0O02] A software based system for controlling a 
decoder in a digrtai television system that uses a virtual 
machine and run time engine for processing digital tele- 
vision data and downloaded applications is descril^ed in 
the PCT application PCT/EP97/02116, This system 
possesses a number of advantages in comparison with 
previously known systems for receiver/decoders, nota- 
bly in regard to the independence of the application lay- 
ers of the system to the hardware elements of the 
manufactured decoder through the use of a virtual 
machine structure. 

[0003] The system described in this application uses 
the principle, of a single file queue^ased structure for 
controlling artd processing events that arise in the sys- 
tem. A number of disadvantages are associated with a 
queue based structure, including a relatively slow 
response to high priority events and an inability to effi- 
ciently handle a number of concurrent inputs into the 
system. As described, the system includes a number of 
process sequencer units. Although the system can pri- 
oritise the operation of such sequencers, once a partic- 
ular process is started, it is not possible to change to 
another. 

[0004] These drawbacks of the structure become par- 
ticularly acute in the case where the receiver/decoder 
includes an interactive application. For example, the 
inability of the system to change tasks in response to a 
priority command combined with the often lengthy time 
needed to download data can result in the system being 
locked into one operation despite commands from the 
user to change to another mode. 
[0005] There is also a need to simplify tine device 
driver structure of this known system. Communication 
between the run time engine and the hardware levels of 
the known decoder is handled by a plurality of device 
drivers, the overall organisation of which is handled by a 
device manager which ^anages the prioritisation of 
event messages and their input into the queue structure 
of the process sequencer units. As discussed in the 
application, whilst the oin time engine is provided by the 
system authority, the device drivers and manager are 
usually provided by the decoder manufacturer, following 
the specifications of the system authority. 
[0006] Differences in interpretation of the specification 
by the decoder manufacturer can lead to problems 
where, for example, the manager does not respect the 
correct classification of priority events. In such a case, 
the queuing system will be disrupted as the events sup- 
plied to the event filter and process sequencer will be 
wrongly identified in terms of their priority and will be 
incorrectiy handled by the queuing system. 
[0007] It is an object of the present invention In its 



broadest and preferred aspects to overcome these 
problems of the prior art system. 
[0008] According to the present invention, there is pro- 
vided an apparatus for processing digital audio-visual 

5 data comprising one or more hardware devices for 
transmission and reception of data, the hardware 
devices having at least one associated hardware oper- 
ating system, the apparatus further comprising a data 
processing system including a multi-tiiread virtual 

10 machine adapted to, inter alia, receive event messages 
signalled by the hardware operating system and to 
assign con-esponding event objects to one or more 
threads, and in which a thread including an event object 
may be suspended during the course of its execution to 

15 permit the execution of another thread. 

[0009] Through the use of a multithread architecture, 
the present invention tiius enables the system to 
respond effectively to the arrival of events received via 
the external interfaces of the device, allowing rapid 

20 treatment of high priority events during the temporary 
. suspension of non-urgent processes. 
[0010] in one embodiment, the virtual machine has a 
pre-emptive multithread architecture, in which a tiiread 
is suspended during the course of its execution upon 

25 the creation of a thread of higher priority Whilst tiiis 
embodiment is prefen-ed for its responsiveness to prior- 
ity events, other embodiments may be envisaged, such 
as a time-slice embodiment, in which the virtual 
machine interrupts execution of a tiiread at pre-deter- 

30 mined periodic intervals to see if another thread to be 
executed exists. 

[001 1 ] Preferably, the virtual machine comprises an 
event manager adapted to respond to an event mes- 
sage signalled by the hardware operating system by 

35 Storing an event object in one or more threads in a pri- 
ority organised tiiread queue. 
[0012] In this way, the prioritisation of events can be 
handled directly by the virtual machine, avoiding the 
problems of the known system, in which events are first 

40 ordered for insertion in the processor queue by low level 
device drivers and managers. As discussed above, the 
implementation of a driver may be variable from one 
manufacturer to another. In contrast in this preferred 
embodiment, event messages are sorted and prioritised 

45 by an event manager within tiie virtual machine, the 
characteristics of which are unchangeable from one 
platform to another. 

[0013] Notwithstanding tiie fact that event handling is 
now effectively carried out by the virtual machine, the 

so system may nevertheless also comprise in certain 
embodiments one or more device drivers to serve as an 
interface between ihe operating system of the virtual 
machine and the hardware level operating system. 
[0014] In addition to events arising from the hardware 

55 operating system, the event manager may also be con- 
figured to respond to e/ent messages arising from 
within the virtual machine or from higher level applica- 
tions. 
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[0015] In prelerred embodiments, the order of event 
objects within a thread may also be prioritised according 
to the priority oi the event and/or the arrival time of the 
event This may be In addition to the Initial prioritisation 
canied out in the assignment of Instructions to threads 
in the thread queue. 

[001 6] In one implementation, the virtual machine may 
also comprise a routing table containing information 
regarding possible event messages and addressable by 
the e/Bn\ manager to enable the event manager to 
determine the thread con-espondence of a received 
event message. This routing table may also be used to 
determine the priority of an event object within a thread. 
As will be understood by one skilled in the art, alterna- 
tive means may also be used. 
[001 7] In addition to an event manager and routing 
table, the virtual machine also preferably comprises a 
scheduler adapted to examine the threads held in the 
priority organised thread queue and to command the 
execution of the thread having the highest priority at that 
time. In order to implement a pre-emptive thread man- 
agement operation, the event manager rmy be adapted 
to signal the arrival of an event message and to cause 
the scheduler to examine the new state of the threads 
held in the thread queue. 

[0018] Whilst the present invention Is particularly 
applicable to a decoder for receiving and processing 
digital television systems, it will be understood that the 
principles of the data processing system set out In this 
application may also be applied to other devices for 
handling digital audio-visual data, such as digital video 
recorders and the like. In the context of a decoder for a 
digital television broadcast, the hardware devices of the 
decoder can include an MPEG demultiplexer together 
with a tuner, a serial interface, a parallel interface, a 
modem arxJ one or more smart card readers. 
[0019] in the present application, the term "^decoder" 
is used to apply to an integrated receiver/decoder for 
receiving and decrypting an encoded broadcast, the 
receiver and decoder elements of such a system as 
considered separately, as well as to a digital television 
receiver for receiving non- encrypted broadcasts. 
[0020] There will npw be described, by way of exam- 
ple only, an embodiment of the present invention, with 
reference to the attached figures, in which: 

Figure 1 shows an overall view of a digital television- 
system; 

Figure 2 shows the elements of an interactive sys- 
tem within the digital television system of Figure 1 ; 

Figure 3 shows the architecture of the software 
based system Implemented within the 
receiver/decoder of the present invention; 

Figure 4 shows the architecture of the virtual 
machine within the system of Figure 3. including in 



particular an event manager package, an interpre- 
tation package and a memory package; 

Figure 5 shows the structure of the interpreter used 
5 in the virtual machine; 

Rgure 6 shows the thread handling within the vir- 
tual machine; 

10 Rgure 7 shows the operation of the event manager 
and scheduler of the virtual machine; 

Figure 8 shows the management of the memory 
pool by the virtual machine. 

15 

DIGITAL TELEVISION NETWORK 

[0021 1 An overview of a digital television system 1 000 
according to the present invention is shown in Figure 1. 

20 . The invention includes a mostly conventional digital tel- 
evision system 2000 that uses the known MPEG-2 com- 
pression system to transmit compressed digital signals. 
In more detail, MPEG-2 compressor 2002 In a broad- 
cast centre receives a digital signal stream (typically a 

25 stream of video signals). The compressor 2002 is con- 
nected to a multiplexer and scrambler 2004 by linkage 
' 2006. 

[0022] The multiplexer 2004 receives a plurality of fur- 
ther input signals, assembles one or more transport 
30 streams and transmits compressed digital signals to a 
transmitter 2008 of the broadcast centre via linkage 
2010, which can of course take a wide variety of forms 
including telecommunications links. The transmitter 
2008 transmits electromagnetic signals via uplink 2012 
35 towards a satellite transponder 2014. where they are 
electronically processed and broadcast via notional 
downlink 2016 to earth receiver 2018, conventionally in 
the form of a dish owned or rented by the end user. The 
signals received by receiver 2018 are transmitted to an 
40 integrated receiver/decoder 2020 owned or rented by 
the end user and connected to the end user's television 
set 2022. The receiver/decoder 2020 decodes the com- 
pressed MPEG-2 signal into a television signal for the 
television set 2022. 
45 [0023] A conditional access system 3000 is connected 
to the multiplexer 2004 and the receiver/decoder 2020, 
and is located partly in the broadcast centre and partly 
in the decoder. It enables the end user to access digital 
television broadcasts from one or more broadcast sup- 
so pliers. A smartcard, capable of deciphering messages 
relating to commercial offers (that is. one or several tel- 
evision programmes sold by the broadcast supplier), 
can be inserted into the receiver/decoder 2020. Using 
the decoder 2020 and smartcard. the end user may pur- 
55 chase commercial offers in either a subsaiption mode 
or a pay-per-view mode. 
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INTERACTIVE SYSTEM WITHIN THE DIGITAL TELE- 
VISION NETWORK 

[0024] An interactive system 4000, also connected to 
the multiplexer 2004 and the receiver/decoder 2020 and 
again located partly In the broadcast centre and partly 
in the decoder, enables the end user to interact with var- 
ious applications via a modemmed back channel 4002. 
[0025] Figure 2 shows elements of the general archi- 
tecture of the interactive television system 4000 com- 
prising in overview four main elements: 

1 . An authoring tool 4004 at the broadcast centre or 
elsewhere for enabling a broadcast supplier to cre- 
ate, develop, debug and test applications. 

2. An application and data server 4006, at the 
broadcast centre, connected to the authoring tool 
4004 for enabling a broadcast supplier to prepare, 
authenticate and format applications and data for 
delivery to the multiplexer and scrambler 2004 for 
insertion into the MPEG-2 transport stream (typi- 
cally the private section thereof) to be broadcast to 
the end user 

3. A data processing system 4008 at the 
receiver/decoder for receiving and processing 
downloaded applications and data and for manag- 
ing communication with tiie other elements of the 
interactive system and the hardware elements of 
the receiver/decoder, tiie system 4008 including a 
virtual machine with a run time engine (RTE) imple- 
mented as executable code installed in the 
receiver/decoder. 

4. A modemmed back channel 4002 between the 
receiver/decoder 2020 and the application and data 
server 4006 to communicate signals instructing the 
server 4006 to insert data and applications into the 
MPEG-2 transport stream at the request of the end 
user. Information may also be passed in tiie other 
direction. 

[0026] The receiver/decoder 2020 includes a number 
of devices for communicating witii exterior devices 
within the interactive system, such as an tuner for tuning 
the receiver, an MPEG demultiplexer for demultiplexing 
the MPEG signal, a serial interface, a parallel interface, 
a modem and one or two card readers adapted to read, 
for example, credit cards or subscription smart cards 
issued with the system. The characteristics of such 
devices are well known in the field of digital television 
systems and will not be described here in any more 
detail. 

[0027] Similarly, tiie sorts of interactive applications 
that may be provided (home t)anking, teleshopping. 
downloading of computer software) will be apparent to 
those in the fiekj and will not be described in more 



detail. While the decoder system architecture described 
below is particularly apt for interactive applications it will 
also be appreciated that the architecture described can 
be used in simpler non-interactive digital TV systems, 
5 such as a conventional pay TV system. 

DECODER SYSTEM ARCHITECTURE 

[0028] Turning now to the architecture of the system 
10 within the receiver/decoder shown in Figure 3, it will be 
seen that a layered architecture is used. The first layer 
4100 represents the operating system of the hardware 
of the receiver/decoder. This is a real-time operating 
system chosen by the manufacturer to control the hard- 
15 ware elements of the receiver/decoder. The real -time 
operating system has a relatively fast response time in 
order to be able to correctly synchronise hardware oper- 
ations. Event messages are passed between this layer 
and the middleware layer 4200 immediately above. 
20 [0029] The data processing system 4008 sits on top of 
the hardware operating system and comprises a mid- 
dleware layer and an application (or more correctly an 
application interface) layer. 

[0030] The middleware layer is written in a language 

25 such as C ANSI and comprises the elements of a virtual 
machine 4250 and a number of interfaces 4260 includ- 
ing a graphical interface 4261, a FLASH/PROM mem- 
ory interface 4262. a protocol interface 4263 and a 
device interface 4264. 

30 [0031 ] As with tiie system set out in patent application 
PCT/EP97/02116 desCTibed in more detail in tiie intro- 
duction, the present invention uses a virtual machine in 
order to provide independence between upper level 
applications and tiie lower level operating system imple- 

35 mented by the manufacturer. 

[0032] The interfaces 4260 provide the link between 
operations of tiie virtual machine and the lower level 
operating system 4100 and also include a number of 
intermediate level application modules more easily exe- 

40 cuted at tiiis level. 

[0033] The application interface (API) layer 4300 com- 
prises a number of high level packages 4310-431 4, writ- 
ten in an object-oriented interpretative language, such 
as Java. These packages provide an interface between 

45 the applications created by the service provider (inter- 
active program guide, teleshopping, internet browser 
etc) arxi tiie virtual machine of the system. Examples of 
such applications are given below. 
[O034] The lower level OS is normally embedded in 

so tfie hardware components of tiie decoder, although in 
some realisations, the lower level OS can be down- 
loaded. The middleware and application interface layer 
packages can be downloaded into the RAM or FLASH 
memory of tiie decoder from a broadcast transmission. 

55 Alternatively, some of all of the middleware or applica- 
tion interface layer elements can be stored in the ROM 
or (if present) FLASH memory of the decoder. As will be 
understood, the physical organisation of tiie memory 
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elements of the decoder is distinct from the logical 
organisation of the memory. 

APPMCATIQN IN TgRFAC^ lAYgR 

[0035] Referring to the application interface layer 4300 
shown in Rgure 3, and as described above, the pack- 
ages in this layer are written in an object oriented lan- 
guage such as Java. Each package defines a set of 
class libraries called on during operation of the system. 
In the present system the following packages are 
installed. 

[0036] LangAJtil Package 4310. These packages 
define the classes necessary for the manipulation of 
objects by the virtual machine. These class libraries 
normally form part of a standard library associated with 
the object oriented language chosen. 
[0037J MHEG-5 Package 431 1 , This package defines 
the classes associated with the manipulation of graphi- 
cal objects on the television display. Such objects are 
distinct from audio-visual data and. can make up, for* 
example, channel identifiers or text laid over displayed 
images. The definition of classes within this package 
should respect the MHEG-5 norms defined by the 
standards ETS 300777-3 and ISO/ISE 13522-5 (and 
the standard ISO/ISE 13522-6 in the case of a Java 
inriplemented system). 

[0038] Toolbox Package 43 1 2. This package contains 
the classes used for downloading and decompression 
of infonnation as well as the classes associated with the 
management of the file system and memory within the 
receiver/decoder and the classes associated with the 
connection to the intemet etc. 
[0039] Device Package 4313. This package defines 
the classes necessary for management of peripherals 
attached to the receiver/decoder, as discussed above 
and including the modem, the smart card readers, the 
MPEG flow tuner etc 

[0040] Service Package 4314. This package defines 
the classes necessary for the implementation of devel- 
oping higher level interactive applications, such as man- 
agement of aedit card data etc. 
[0041] DSMCC-UU Package 4315. This package 
implements the protocols necessary for communication 
between a client and a server for data file search and 
reading. Implementation of this package should respect 
the norm ISO/IEC 13818-6 and directives defined in 
DAVICpartS. 

[0042] A further layer of interactive applications, writ- 
ten by the service provider and downloaded during 
broadcast as in conventional systems, will be laid over 
the interface packages defined above. Depending on 
the applications to be introduced, some of the above 
packages may be omitted. For example, if the service 
provider does not intend to provide a common way for 
data reading, the DSMCC-UU package may be left out 
of the final system. 

[0043] The packages 4300 provide class libraries for 



an object-oriented programming environment. Their 
class behaviour will depend on the language chosen. In 
the case of a Java application, for example, a single 
inheritance class structure will be adhered to, 

5 

INTERFACE lAYEH 

[0044] As shown, the interface layer is composed of 
four modules, a graphics module 4261 , a memory file 

10 management module 4261, a protocol module 4263 
and a device nnanager 4264. Whilst the modules at this 
level are described as interface modules their function is 
to provide a "glue" layer for the implementation of the 
application interface packages and for the operation of 

15 the virtual machine generally. 

[0045] The graphics module 4261, for example, pro- 
vides the creation and management of graphical 
objects. It asks the low level OS to display basic graphic 
shapes such as single pixels, lines, rectangles etc. The 

20 implementation of this nnodule depends on the graphics 
■.capability of the low level manufacturer's OS. In some 
ways complementary to the MHEG-5 package 4311, 
these functions may be more efficiently executed at this 
code level than in the high level code chosen for the 

25 application layer above. 

[0046] In-a similar manner, the mennory file nrmnage- 
ment module 4262 includes low level read/write file 
commands associated with the memory components of 
the system. Typically, the hardware operating system 

30 only includes commands necessary to read/write a sec- 
tor or page within a memory component. As with the 
graphics module 4261, this module enables a set of 
simpler lower level applications to be efficiently intro- 
duced in the system. 

35 [0047] The protocol management module 4263 
defines a library of communication protocols that may 
be called upon in communications via, for example, the 
TCP/IP layer of the decoder. 

[0048] The device manager 4264 is slightly different 
40 from the other modules in this layer in that it provides 
the link or interface between the hardware operating 
system and the layers above, including the other mod- 
ules in the interface layer and the virtual machine. Com- 
mands or event messages that are received/sent to the 
45 hardware OS from the virtual machine, for example, are 
necessarily passed by the device manager for conver- 
sion according to the interface specifications between 
the two levels. 

50 VIRTUAL MACHINE DESCRIPTION 

[0049] Referring now to Figure 4, the structure of the 
virtual machine 4250 used in the system of the present 
invention will be described. The virtual machine used in 
55 the present invention is a pre-emptive multithread type 
machine. The general characteristics of such a machine 
are known in other contexts outside of the audio-visual 
and digital television fields and the following description 
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will focus on those areas that are the most specific to 
the present application. 

[0O5O] The virtual machine is composed of a number 
of elements, which interact broadly as shown in Figure 
4. 5 
[0051] The scheduler 4270 composed of a thread 
manager service 4271 and a monitor manager service 
4272 forms the heart of the multithread machine. The 
scheduler 4270 orders the execution of threads created 
by applications externally of the virtual machine and io 
those created by the virtual machine Itself (e.g. a gar- 
bage collection thread as discussed below). 
[0052] The event manager 4273 handles an event 
routing table and the lists of events subscribed to by the 
threads and centralises the dispatch of event treat- is 
merits. 

[0053] The memory manager 4274 handles the allo- 
cation and disallocation of the memory zones within the 
system memory and also handles the removal from the 
memory of non-referenced objects (garbage collection). 20 
[0054] The class manager 4275 charges the classes 
of the application code downloaded in a broadcast sig- 
nal, interacting with the security manager 4280 to check 
the integrity of downloaded code and with the file man- 
ager 4276. which implements the applications. 25 
[0055] The file manager 4276 carries out the imple- 
mentation of the system files and the handles the mech- 
anism of downloading of interactive applications and 
data. 

[0056] The security manager 4280 handles the level so 
of access permitted to downloaded applications, some 
applications having the ability to carry out more opera- 
tions than others in relation to the file system. 
[0057] The interpreter 4277 comprising a bytecode 
interpretation service 4278 and a "m-code" interpreta- 35 
tion service 4279 handles the interpretation of applica- 
tions written in these two codes, bytecode being 
associated with Java applications and m-code being the 
name given to a proprietary code developed by the 
applicants. As will be discussed, further interpretation 40 
services can be added if desired. 
[0058] The operation and implementation of the class 
manager, file manager |nd security manager may be 
conventional. The description will now focus on the 
operation of the interpreter, the scheduler and event 45 
manager and the memory nnanager. 

INTERPRETER 

[0059] Referring now to Figure 5, the operation of the sc 
interpreter 4277 used in the embodiment of the present 
invention will now be described. As discussed in the 
introduction, the disadvantage of conventional operat- 
ing systems used in decoders proposed to date has 
been their reliance on a single type of code for the high 55 
level applications. Although the code chosen may be a 
commercially available and widely known application 
code, problems can nevertheless arise in the case 



where it is necessary to maintain a field of a number of 
decoders using different applications written in a 
number of codes. The interpreter of the present system 
permits the interpretation of a number of types of code. 
[0060] As shown, files arriving in the system, whether 
bytecode classes or m-code modules are evaluated by 
the module class manager 4500 according to the struc- 
ture of the file, such that the application code delivered 
to the interpreter 451 0 has an indication of format. In the 
case of a bytecode application, for example, the down- 
loaded class file will have a characteristic identification 
header of 4 octets followed by a version number, also of 
4 octets. The interpreter may distinguish between the 
codes on the basis of the presence or absence of this 
bytecode header. 

[0061] In other embodiments, other characteristics of 
the code types may be used to distinguish between any 
number of application languages, such as the file name, 
for example. 

[0062] Depending on the result of the format indicator, 
bytecode instructions are sent to the bytecode inter- 
preter 4278, where they are executed with reference to 
a function library 4520 associated with the byte code 
instructions, as is conventionally the case with interpre- 
tative code instructions. The function library of native 
code instructions is defined within the virtual machine. 
[0063] in the case of m-code instructions, these are 
passed to a m-code interpreter 4278. The majority of 
the m-code instructions may be implemented and exe- 
cuted with reference to the function library 4520 associ- 
ated with byte-code instructions, and the interpreter 
4278 calls on the library 4520 to execute such m-code 
functions wherever possible. 

[0064] In some circumstances, however, some m- 
code instructions may need specific execution functions 
not easily executable with reference to a common func- 
tion library. In such cases, it may be envisaged that the 
instructions be implemented with reference to a sepa- 
rate function library 4530. 

SCHEDULER AND EVENT MANAGER 

[0065] The operation of the scheduler 4270 and event 
manager 4273 will now be discussed, with reference to 
Figure 6 which shows the life of a thread within the sys- 
tem and Figure 7 which shows the notification of an 
event to a thread by the system in response to an event 
signalled by the lower level run-time operating system. 
[0066] The description will concentrate on the han- 
dling of the creation of a thread which represents an 
execution context in particular resulting from a signalled 
event. It will be understood that a thread may be created 
with the initiation of a command generated by a higher 
level application to be sent to the hardware OS and by 
the return of this commarxJ. A thread may also be cre- 
ated within the virtual machine itself, eg a garbage col- 
lection thread. 

[0067] As mentioned above, the present ennbodiment 
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reiies on a pre-emptive thread handling virtual machine 
such as that found in Java based systems. In such a 
machine, a plurality of threads are generated and stored 
in a thread queue. The scheduler inspects the thread 
queue and selects the thread with the highest priority to 5 
be executed. Mormally, the thread that is being executed 
has the highest priority, tjut such a thread may be inter- 
aipted by a thread of yet a higher priority as is conven- 
tional in pre-emptive threaded systems. In such a case, 
the state of the interrupted thread is stored and the 10 
thread re-activated once it reselected to be executed. 
[0068] In certain cases, a thread may itself include a 
so-called "yield" instruction which causes the scheduler 
to suspend the execution of the thread and to inspect 
the thread queue for any other threads to execute. The is 
yield instruction may be present in low priority internally 
generated tasks, such as a garbage collection function 
carried out by the system in order to remove unused 
objects from the memory of the system. 
[0069] These aspects of the system are shown in Fig- 20 
ure 6. The creation of a thread at 4550 giyes rise to a 
thread stored in the thread queue 4551: The newly cre- 
ated thread has the state "inif at 4552. If no other 
thread has higher priority, the thread is executed by the 
instruction startQ and will have the state "executable" at 25 
4553. If the instruction stopQ is executed in the thread, 
the thread becomes "dead" at 4554. The thread may 
equally achieve this state if completed as indicated by 
the runQfini instruction. If a yieldQ instruction in the 
thread itself arises, or a suspendQ instruction external 30 
of the thread is executed, the thread is suspended and 
given the state "non-executable" at 4556. 
[0070] Referring now to Figure 7, the interaction 
between the lower level operating system 4100, the 
event manager 4273 and the scheduler 4270 will now 35 
be described. Raw events signalled by the run-time 
operating system 4100 are passed via the device man- 
ager 4313 to the event manager 4273. In a preferred 
realisation, some prioritisation of the received events 
may be can-ied out by the device manager 4313 and/or 40 
the multitask system used in the operating system 
4100. However, as will become clear, one of the advan- 
tages of the present system lies in the fact that unlike 
the system described in PCT/EP97/021 16. the handling 
of events is managed within the virtual machine 4250, 45 
thus enabling creator of the middleware layer to achieve 
complete control over the event handling procedure. 
[0071 ] In the present embodiment, events sent via the 
device manager 4313 are classified by their code and 
their type. The code identifies the characteristics of the so 
event, for example, in the case of an event generated 
through operation of a remote control associated with 
the decoder, the code can identify the button 
depressed. The type identifies the origin of the event, 
e.g. the remote control. ss 
[0072] Upon receipt of an event signal, the event man- 
ager 4273 uses a routing table 4560 to determine the 
event priority and thread destination and inserts a corre- 



sponding event object 4564 into one or more threads 
4561 located within the priority based thread queue 
4562. One or more event objects 4564 may be stored 
within a given thread as represented at 4563. The event 
objects 4564 are stocked within the thread according to 
their priority classification. Event objects within the 
thread of an equal priority are classified by their time of 
arrival (FIFO). 

[0073] Upon receipt of an event, the event manager 
4273 signals its an^ival to the scheduler 4270, which 
then examines the thread queue to see if a thread has a 
higher priority than the thread cun-ently being executed. 
If so, the current thread is then suspended as described 
above and the new thread executed. In this manner a 
pre-emptive thread handling system is implemented. 
[0074] In this way, the preferred embodiment allows 
efficient handling of threads in the decoder so as to per- 
mit the system to respond quickly to event calls, even in 
the case where the system is processing an existing 
prior event. The disadvantages of the known single 
processor queue system are thereby overcome. 
[0075] Whilst the prefen-ed embodiment has been 
described in relation to a pre-emptive system in which 
the arrival of an event causes the event nnanager to sig- 
nal the scheduler to interrupt execution of a thread, 
other implementations are possible. For example, in a 
time-slice system, the scheduler can pei'iodically inter- 
rupt execution of a thread to examine the state of the 
thread queue. Altematively the scheduler can be 
adapted to interrupt execution of a thread to examine 
the thread queue after each instruction in that the 
thread is treated. 

MEMORY t^ANAQER 

[0076] As will be appreciated, in the context of 
receiver/decoder, the management of the memory pool 
within the system is particularly important, since mem- 
ory space is relatively restricted as compared to for 
example, a PC or other hard disk based platform. In the 
following description, the memory pool corresponds to 
the memory space within the RAM of the 
receiver/decoder. However, as mentioned above, the 
correspondence between the physical and logical 
organisation of the memory is not exact and the mem- 
ory pool described below may be located in or shared 
between other physical memory devices, such as a 
FLASH memory, an EEPROM etc, within the 
receiver/decoder 

[0077] Referring now to Figure 8, this shows the 
organisation of the available memory in the system. It 
will be seen that the memory space is shared between 
a pool of handles 4600, a pool of displaceable objects 
461 0 and a pool of non-displaceable objects 4620. 
[0078] Each object in the pool 4610 is identified by 
and corresponds to a handle stored in the pool 4600. 
The relation between a handle and its corresponding 
object is managed by the memory management pack- 
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age 4274 (see Figure 4) which also controls the access 
to the pool. All calls to objects in the pool are made by 
its handle. The boundary between the pools 4600 and 
4610 is movable. When a new object is to be stored in 
memory a handle is created in the pool 4600 including a 
pointer to the address of the object within the pool 461 0, 
In such a case, the list of handles will be increased by 
one. The handles are organised in a list formation in the 
pool to permit compactage by the memory manager. 
[0079] Objects will be allocated in the pool as needed 
and according to the space available. In the case that an 
object allocation is demanded which requires more 
space in one block than is available, it will be necessary 
to compact the objects already allocated in the memory. 
The compaction of the objects in the memory can be 
carried out according to any known compacting algo- 
rithm, for example, a copy-compact algorithm. In the 
present embodiment, the Mark Sweep compact algo- 
rithm is used. In order to compact space, the objects are 
moved around in the zpne 461 0, so as to group objects 
more closely together, avoiding any spaces between 
adjacent objects. In this way. all free memory space is 
clustered together in a block so as to allocate for a new 
object in the pool 4610. 

[0080] As mentioned above, the memory manage- 
ment package maintains the correspondence between 
handles in the pool 4600 arxJ objects in the pool 4610 
and the new addresses of the objects in the pool will be 
updated into the equivalent handles for future access. 
[0081 ] Whilst the use of a handles to access certain 
objects enables the system to optimise memory location 
in the pool, the process increases the time needed to 
access such objects, since it is always necessary to first 
retrieve the handle in order to look up the address of the 
object in certain situations and for objects correspond- 
ing to certain designated events a more rapid access 
time may be required. 

[0082] In such a case, the objects can be allocated in 
a pool of non-displaceab!e objects 4620. The address of 
such objects is fixed within the pool. There is thus no 
need for the creation ot a handle and the objects are 
used directly by the system, thereby simplifying the 
access procedure for th^se-special objects. Again, as 
with the boundary between the pools 4600 and 4610, 
the boundary between the pools 4620 and 4610 will be 
shifted depending on the information stocked in the pool 
4620. 

[0083] In the event, for example, that a non-displace- 
able object is be allocated to the pool 4620 and there is 
insufficient space due to the arrangement of displacea- 
ble objects in the pool 4610, a compaction of the dis- 
placeable objects may be carried out, as described 
above. Once the objects In the pool are reorganised so 
as to liberate the maximum amount of space it may then 
be possible to allocate a non-displaceable block in the 
pool 4620. 

[0084] The choice of which objects are displaceable 
and which objects are non-displaceable is at the discre- 



tion of the designer. For example, objects con^espond- 
ing to the system may be chosen as non-displaceable in 
view of the Importance of these objects, whilst high level 
application objects may be displaceable. In certain 
5 instances, displaceable objects can be temporarily 
locked into place so as to be considered as non-mova- 
ble objects. 

[0085] In order to eliminate unwanted objects from the 
memory pool the system may also include a so-cailed 

10 garbage collection. This involves the creation of a spe- 
cial garbage collector thread of the lowest priority which 
will be addressed by the scheduler in the pvent that no 
other threads are currently stored in the queue. Upon 
execution, all displaceable objects currently allocated in 

15 the pool thai are not being referenced at that time will be 
freed. The garbage collector thread may also carry out 
compaction of all other displaceable objects along the 
fines described above. 

[0086] The creation of a garbage collector thread is 
20 known in the context of other multithread systems used 
in other applications outside of a digital television sys- 
tem and will not be discussed in any further detail here. 
However, it will be appreciated that use of a gart>age 
collection procedure in connbination with the other mem- 
25 ory management techniques desaibed above provides 
particular advantages in the present context. 

Claims 

30 1. An apparatus for processing digital audio-visual 
data comprising one or more hardware devices for 
transmission and reception of data, the hardware 
devices having at least one associated hardware 
operating system, the apparatus further comprising 

35 a data processing system including a multi*thread 
virtual machine adapted to, inter alia, receive event 
messages signalled by the hardware operating sys- 
tem and to assign corresponding event objects to 
one or more threads, and in which a thread may be 

40 suspended during the course of its execution to 
permit the execution of another thread. 



An apparatus as claimed in claim 1 in which the vir- 
tual machine has a pre-emptive multithread archi- 
tecture, in which a thread is suspended during the 
course of its execution by the creation of a thread of 
higher priority. 



45 



50 



55 



An apparatus as claimed in claim 1 or 2. in which 
the virtual machine comprises an event manager 
adapted to respond to an event message signalled 
by the hardware operating system by storing an 
event object in one or more threads in a priority 
organised thread queue. 

An apparatus as claimed in claim 3, in which event 
messages sent from the hardware operating sys- 
tem to the event manager are first processed by 
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one or more device managers within the data 
processing system. 

5. An apparatus as claimed in claini 3 or 4. the event 
manager further being adapted to respond to an 5 
event message generated internally by the virtual 
machine or received from a high level application 
within or external of the data processing system. 

6. An apparatus as claimed in any of daims 3 to 5, in io 
which the event manager classiiies event objects 
internally within a thread according to the priority of 
the event message and/or the arrival time of the 
event message. 

75 

7. An apparatus as claimed in any of daims 3 to 6, in 
which the virtual machine further comprises a rout- 
ing table containing information regarding possible 
event messages and addressable by the event 
manager to enabje the event manager to determine 2o 
the thread con-espondence of a received event 
message. 

8. An apparatus as claimed in claim 7 in which the 
routing table contains information to enable the 25 
event manager to determine the priority of an event 
object within a thread. 

9- An apparatus as claimed in any of daims 3 to 8, in 
which the virtual machine further comprises a 30 
scheduler adapted to examine the threads held in 
the priority organised thread queue and to com- 
mand the execution of the thread having the highest 
priority at that time. 

35 

10. An apparatus as claimed in claim 9, in which the 
event manager is adapted to signal the arrival of an 
event message and to cause the scheduler to 
examine the new state of the threads held in the 
thread queue. 

11. An apparatus as claimed in any preceding claim in 
which the apparqjus is a decoder for a digital televi- 
sion system 

45 

12. An apparatus as claimed in any preceding claim in 
which one of the devices comprises an MPEG 
demultiplexer. 

13. An apparatus as claimed in any preceding claim in so 
which the hardware devices may comprise at least 
one of the following: a tuner, a serial interface, a 
parallel interface, a modem and one or more smart 
card readers. 
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